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lliis memo documents the operation of the Alto Gateway program. You are assumed to be 
reasonably familiar with Altos. FamiHarity witli Mesa will be very helpful. You might also want to 
read Ed Tafl's memo titled "Nova Gateway Operation". It is stored on 

[IVY] < Portola > GatewayOperation.press. 

I have avoided any details of the current network topology since it is changing frequently. There 
are two documents that are very helpful when trying to track down network troubles. They are 

[MAXC] < AltoDocs > AltoNetwork.press and [MAXC] < SYSTEM > Pup-Network.txt. I Suggest that yOU keep a 
reasonably up to date copy handy. 

lliere is also a one page summary on Iris] < MesaGate > AltoGateSummary.bravo&press. 

1. Normal Operation 

Power Up and such 

The only problem with turning a Gateway Alto on and/or off is setting the time if there is 
not another Gateway connected to the normal Ethernet. If the Alto asks you to set the date 
and time, the trick is to use text such as in "Jul" rather than a number for the month. If 
you get really frustrated, tc or siniT-swAT will also get you past this problem. 

Starting the Gateway Program 

Type the command Gateway followed by carriage return. ITic program will, read the 
parameter file, print out a few messages about boot files, print a few informational messages, 
pause for a while, and finally print the message "Gateway of date-time in operation". At 
this point the Gateway program is running. However, it takes approximately one minute for 
new routing information to be propagated throughout the inter-network, so it may not be 
possible for connections to be established through the Gateway during the first minute after 
the Gateway program is started. About a minute afi:er the program is started, the display 
will get turned off. 

The Alto Display 

The display is turned off shortly after the Gateway program is started. This conserves CPU 
cycles, and saves the core that would be needed by the bitmap. Noitnally the screen will be 
all black, [f you type anything on the Keyboard, the picture will normally reappear. If the 
disk is active, the screen will switch to all white. This happens while the Gateway is 
sending a boot file, searching the mxmc lookup data base, or receiving a new copy of a file. 
If you want to see if the Gateway is alive, watch the cursor, or hit the space bar. 

Whenever any character is typed in, the display will be turned on for 30 seconds. If the 
Gateway program is ruiuiing in debugging mode, the display is turned on for 5 seconds 



Alto Gateway Operation 2 

whenever it prints out an infoiTnational message. Normally, it stays off, and the messages 
can be found in Mesa.typescript if you are interested. 

The cursor will move one step to the right for each Pup that is forwarded, 50 steps left for 
each Pup that cannot be forwarded, and one step down for each Pup received by the Echo 
server or the Miscellaneous Services server. 

If the Gateway has an SLA line driven by an eia board, there are troubles keeping the 
clock accurate when the display is on. To avoid sending out inacurate infomiation, the Pup 
Time Server is disabled whenever the display is lumed on. It is automatically reset when 
the display goes off. 

Gateway Program Commands 

The Gateway program has a simple command interpreter that responds to single-character 
commands typed on the keyboard. Whenever a character is typed, the display is turned on 
for 30 seconds. 

If you are using an EIA board, any command will disable the time server. 

The commands are as follows (the "?", or any unrecognized character elicits this list): 

Gateway Statistics 

Prints out a summary of various operating statistics, including the length of time 
Gateway program has been running (hours:minutes:scconds), the number of times 
each server has been invoked (explained later in this memo), and a matrix showing 
number of packets forwarded from one directly-connected network to another. The 
number of discarded packets is also listed. Discard of packets is not cause for 
alarm: it is a normal consequence of the great disparity in speed between the 
Ethernet and the leased lines, and does not give rise to loss of information in file 
transfers or terminal connections. 

SLA Statistics 

Prints out operating summaries for the Synchronous Line Adaptor (sla) i.e. the ElA 
board or the CommProc. For each line, the number of packets successfully sent 
and received on that line is printed, followed by the number of instances of three 
types of errors: CRc: (Cyclical Redundancy Check) errors, Sync errors (bit 
synchronization was lost), and Control sequence errors. ITie total number of errors 
should be much less than one percent of the packets successfully received. If a high 
error rate occurs on a single in-use line (whose state is "Up"), the line or modem is 
suspect, whereas if frequent errors occur on all lines (or particularly on "Looped 
back" lines), the SLA interface is suspect. 

ITiis command also prints out the SLA routing table. Under normal circumstances, 
the routing lable for a particular Gateway should show that it can reach all other 
Gateways through one or more of the connected lines. 

Reset Time 

71ie Gateway program maintains the current date and time, which it gives out to 
other hosts that request it. ITie date and time are obtained from another Gateway 
when the Gateway program is started. 'Hie Reset Time command causes the local 
date and time to be invalidated so as to force the Gateway program to reset itself 
from another Gateway. 'I'his is necessary if the local time has become incorrect. 

Probe for New Directory 

A data base of host names and addresses is maintained at Pare and distributed to all 
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Gateways for use in responding to name lookup requests from Altos, llie data base 
distribution procedure is automatic, with requests for data base update generated 
once per hour. ITie Probe for New Directory command simply forces such an 
update to occur immediately. 



Local Routing Table 



Echo 



Debug 



This command prints out the routing table used by the Pup Soflware to determine 
where to send a pup to get it to its final destination. hops means that this 
gateway is directly connected to that network by tlie net and host number indicated. 
If the hop count is greater tlian 0, then the pup will be forwarded to another 
gateway at the indicated address for further processing. 



ITiere is an Echo user program built into the Gateway. It is very similar to the one 
in PupTest. If you are Echoing to yourself, the $ won't get printed, but the cursor 
will move down one step each time a packet gets echoed. 



ITiis command causes control to be given to the Mesa Debugger (if there is one on 
the disk). From within the Debugger, the Gateway program is resumed by typing p 
(for Proceed) and confirming with a return. 



Toggle Display 



This command toggles a lock on the display. If The display was off, or on 
temporarily, it will be turned on, and the 30 second timer will be disabled. If it was 
on, it will be turned off. If you think the display will timeout, but you want to be 
sure that it will go off without waiting, hit the T key twice. The first one will lock 
the display on, and the second one will turn it off. 



This belches forth reams of statistics that are probably only interesting to 
programmers and/or hardware debuggers. 

< SPACE BAR> 

lliis is a dummy command that just turns the display on for 30 seconds. 

Boot File Tabic 

This just prints the table used by the Boot Server. It includes counters so you can 
see which files are really used in case the disk gets full. 



Cache for Name Lookup Sener 



Quit 



This prints out the current contents of the cache maintained by the Name Lookup 
server. 



Terminates the Gateway program and causes control to return to the Alto Executive. 
There will be a delay of about a minute and a half while the Gateway program 
gives other hosts a chance to learn about alternate routes. 



Bugs 
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If the Gateway program gets into trouble, it will probably print a message on the display 
and wait for a person to do something. At this point, there are two options. If you have 
the Mesa Debugger on your Gateway disk, you can get to it and poke around. Normally 
there won't be room for it. In that case, you can only get to SWAT. I think I can do a 
reasonable job of diagnosing bugs if you are careful to save swatee an the right time. ITie 
trick is to be sure the the right information is there, and to avoid clobbering it. If the 
Gateway program is waiting for you to hit swat, do so. That will write the current core 
image into swatee. The Alto will then go to either swat or the Mesa Debugger. In either 
case, reboot it. tK or SIIIFT-SWAT will overwrite swatee. Then ftp swatee away to a safe 
place. Remember that ITP only knows how to talk to machines that are connected to the 
normal Ethernet board. If you don't have an IFS handy, you can store it on another Alto 
until you get the Gateway back up again. Please send me a message telling me where you 
put it. 

There are three general categories of troubles. The first is a problem during initialization. 
Hopefully, the text will be sufficient to solve the problem. The most likely cause is an error 
in GateParametcr.txt. If you run into a message that is too cryptic, please let me know, and 
I will fix it. The second is an uncaught SIGNAL. It will be printed in octal, and a listing of 
Gateway .signals (from [IRIS] < MesaGate > Gateway.signals > ) will probably help translate it into 
English. The third catagory of trouble is an inconsistency discovered by die Pup Software. 
Again an octal number will be printed, and you will need an up to date copy of 
DriverDefs.mesa to translate it into EngHsh. Even if you can translate it, it probably won't 
help you much, but it may help me. 



2. Functions Performed by the Alto Gateway 

The primary purpose of the Gateway is to forward Pups (Pare Universal Packets) from one network 
to another. However, the fact that the Alto is somewhat underutilized by this task and that it is in 
operation all the time makes it a desirable source of other services as well. These services are 
necessarily limited to those that are relatively easy to implement and whose resource requirements 
don't significantly impact the primary role as a Gateway, but they make life considerably more 
pleasant for Alto users than would be the case were these services not available. 

The Gateway program provides the following services: 

Gateway Information 

This service is actually related intimitely with the Alto's role as a Gateway. It provides 
routing information to all hosts on directly-connected networks. It is by means of this 
routing information that Pup sotlware such as m? is able to communicate with hosts on 
other networks. 

Date and Time 

The Gateway program maintains the date and time in a form usable by Altos. The SetTime 
EXEC command obtains the date and time by this means. 

Name Lookup 

This service translates inter-network ncmie/address expressions into addresses usable for 
communication. When an Alto subsystem is requested to establish contact with a host 
addressed symbolically (e.g., "Maxc"), it generates a name lookup request, to which the 
gateway responds by supplying the corresponding intcr-network address (e.g., "3#2O0#"). 



Boot 



Altos are capable of boot-loading over the Ethernet if a suitable server is available to 
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provide the boot files. The Alio Gateway provides this service for a limited set of boot files 
that are useful on an Alto with no disk loaded or with a disk that won't boot (e.g., DMT, 
Scavenger, ftp, CopyDisk, and a NetExcc providing more convenient access to the other 
boot files), lliere is no intention, however, of making available a complete set of Alto 
subsystems by this means. 



Echo 



lliis service consists simply of a process that echoes all received packets back to their source. 
It is useful for hardware and software diagnosis. 

In addition to these services, the Gateway program also implements several internal support 
protocols, such as the one that automatically updates the network directory data base. 

3. Contents of the Gateway Disk 

ITie Alto Gateway disk contains all of the files needed for normal operation of the Alto Gateway. 
Since space is tight, it probably does not contain much else. 

Gatcway.imagc 

"^The Gateway program itself This file is updated when a new version of the 
Gateway program is released. 

GateParameter.Txt 

A parameter file that specifies the configuration for this particular gateway. All 
Gateways run the same Gateway program, and differences in configuration are dealt 
with by this parameter file. ITie specifications in this file include: 

The inter-network addresses (network and host numbers) of all network 
interfaces installed in the machine. 

An empirically-determined correction for regulating the clock in sofi^ware. 

The association between boot file numbers and names. 

'ITie name of the br file that contains tlie microcode to be loaded into the 

RAM. 

This file is likely to be changed only to add new boot files or adjust the clock 
correction. 

MesaGatcEIA.br or McsaGatcCP.br or .... 

This is the microcode loaded into the RAM. 

Pup-Nctwork.Directory 

The local copy of the inter-network name data base. The master copy is 
[MAXC] < System > Pup-Neiwork.Directory. ITiis file is updated automatically by the 
Gateway program. There must be one on the disk before the Gateway program will 
start up. 

DMT.Boot, Chat.boot, NcwOs.Boot, FTP.Boot, Scavcnger.Boot, CopyDisk.Boot, 
NetExcc.boot, and a number of others 

These arc Alto bootstrap files, given out by the Gateway program when an Alto is 
boot-loaded over the Kthcrnet. These files arc updated occasionally when new 
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versions of the programs are released at Pare. They have been "reformatted" so 
that they are not useable by the BootFrom command to the Exec on the Gateway 
Alto. 

Gatc.ScratchS, NevvGateway.image 

Gate.ScratchS is a temporaty file used while getting a new version of Pup- 
Network.Directory and during remote updating of files. There must be enough 
room on the disk for it to hold a copy of the biggest file that will ever be remotely 
updated. NewGatewayJmage is a temporary copy of the Gateway program used 
when remotely distributing a new verrion of the Gateway software. It is needed for 
remote updating and automatic restarting because Mesa uses Gateway. image for 
code swapping, and is automatically deleted by the Restart command from 
GateControl. 

SYS.boot, Swat, Swatec, Executive.riin, FTP.run (and whatever) 

These are just the normal files/programs needed to get any Alto off the ground. 
Note that you will probably need FTP to update anything on the Gateway disk if 
the Gateway program is busted since you can't boot it over the Ethernet. 

Mesa.typescript 

Mesa.typescript is a typescript file of everything that gets printed on the Alto 
display. It is reset whenever the Gateway program is restarted. Every now and 
then, the Gateway program pecks at it, and throws away everything but the first few 
pages if it gets bigger than 100 pages.. 

RimMesa.run 

RunMesa.run is the bootstrap program that loads the Mesa microcode into the ram 
if you don't have a ROMi, and then loads GatewayJmage into core and starts 
running it. 

Xdebug.imagc, McsaDebugger, Debug.typcscript, Windcx.bcd, Fetch.bcd 

ITiesc are the Mesa Debugger. They will be on your disk only if it is setup for 
debugging -- there isn't room for them normally. NB: Do not move or delete any 
of them unless you know what you are doing. They contain FPs. 

Gateway.synibols, Mesa.syrnbols, BuffcrDcfs.bcd, DrivcrDcfs.bcd, ... 

These are the symbols tables for the Mesa Debugger. Again, they will be on your 
disk only if you are chasing a nasty bug. 

4. Gateway Disk Maintenance 

The Gateway software includes the capabiUty for remote updating of files on the Gateway disk. It 
is also possible to remotely command the Gateway to restart, to reset its date and time, and to 
perform other operations. We use this remote control capability at Pare to release new versions of 
the Gateway program and to update the boot files. ITierefore the following procedures should not 
be needed in the ordinary course of events. 

Note that you are in deep trouble if your last Gateway disk gets clobbered. It is a very good idea to 
keep a backup copy. You can easily make one using CopyDisk.run. A Gateway disk can also be 
configured to run on any Alto. It won't be able to forward packets to any other network, but it will 
provide luxuries like a a Time server and a Root server which make working on Altos much more 
pleasant. 
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Obtaining Updated Files 

This section describes procedures for obtaining new Gateway software or other files ft*om Pare and 
installing them on the Gateway disk. This involves stopping the Gateway program briefly, so one 
should first make certain that there are no users who might be affected. 

The following procedure assumes that the file being updated is Gateway .image, but it applies to any 
other file. The procedure requires use of a second Alto connected to the same Ethernet as the 
Gateway Alto. 

1. While the Gateway is still in operation, run ftp on an second Alto, connect to IRIS, and 
retrieve the file < McsaGate > Gatcway.image. After closing the connection to IRIS, leave the Alto 
running FfP. The boot files come from [iVY] < Poriola > and [MAXC] < Alto > . 

2. Type the Quit command on the Gateway keyboard to return control to the Alto 
Executive. 

3. Run the ftp program on the Gateway Alto, connect to the second Alto, and retrieve 
Gatcway.image. Note that since no name server is mnning at this point, it is necessary to 
refer to the second Alto by number rather than name (e.g., if its Ethernet address is 123, 
you Open a connection to "123#"). After retrieving the file, quit out of FFP to the Alto 
Executive. 

4. If desired, back up tlie Gateway disk. 

5. Restart the Gateway program by issuing the Gateway command. 

One might wonder why it is not possible simply to connect directly to mis from the Gateway in 
order to retrieve files. In order to do this, ffp would have to communicate over the SLA line to 
Pare. However, ftp (and other standard subsystems) does not contain the software for driving the 
SLA interface, but only contains a driver for the Ethernet. Hence, ffp running on the Gateway can 
communicate only with machines on the directly connected Ethernet. 

5. PupTcst Operation 

PupTest is a program developed primarily for checkout of the Pup software; however, some of its 
capabihtics are helpful in locating and troubleshooting network problems. Be sure to keep a few 
copies of PupTcst.run on various disks because you can't boot it from the Gateway when you really 
need it. 

We describe here only those PupTest commands useful for troubleshooting netwotk problems. 

The usual symptom of failure is likely to be that a user at a remote location is unable to access 
Maxc or some other machine not on the local Ethernet. There are a multitude of problems that can 
cause this, and one should not jump to the conclusion that the leased line or the Gateway is down. 
The following procedure should pinpoint the failing link. 

The simplest test is to try to connect to some other server on the same remote network. If you can 
connect to cither MAXC2 or ivy, but cannot connect to maxc, then maxc is probably down. 

The PupTest command used in this procedure is Echo. It requests the name or address of a host 
running an Echo Server, and it then sends Echo requests to that server. All Gateways have Echo 
servers, and any machine running PupTcst itself has an Echo server. For each reply PupTcst 
receives, it prints "!", and if no reply is received, it times out after 1.5 seconds, prints "?", and tries 
again. It prints "#" whenever it gets an packet with an incorrect sequence number. Normally this 
happens just after it printed a "?", which simply means that it didn't wait long enough. The test 
terminates when any key (e.g., space) is pressed. 

1. Run PupTest on two Altos connected to the same Ethernet, and direct one of them to 
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Echo to the other. One should address the other Alto by number rather than name; e.g., if 
the other Alto's Ethernet address is 123, one should say "Echo to: 123 #". If this doesn't 
work, then the local Ethernet is broken. It is not necessary for the Gateway to be up for 
this test to work. 

2. Echo to the local Gateway; that is, say "Echo to: n#", where n is the Gateway's 
address on the local Ethernet. If this doesn't work, then the Gateway program is down or 
the Gateway or its Ethernet interface is broken. 

3. Echo, in turn, to each of the other Gateways along the path from the local Gateway to 
the unreachable destination. The topology is geting pretty complicated now, so you will 
have to be careful doing this. (It should be possible to reference these machines by name 
since the name lookup is performed by the local Gateway, which is known to be up by step 
2.) If this doesn't work, then there are a number of possibilities, some of which can be 
checked out by running PupTest on the Gateway (see step 4). If it is possible to echo to 
the last Gateway along the path to some desired host, then the most hkely reason for 
inability to reach that host is that the host itself is down. If it is possible to echo to the 
second Gateway along the path to the unreachable destination (the local Gateway is the 
first), but it is not possible to echo to the last Gateway, then the failure is in the first 
unreachable Gateway or the modems or leased line between it and the next nearer Gateway. 
Determining which component has gone down requires cooperation with personnel at other 
sites. 

4. Unplug the line to the modem and put in an echo plug. Run PupTest on the Gateway 
Alto. (You will need a reasonably up to date version of PupTest. It didn't learn about SLA 
lines until August of 1978.) Be sure to have an accurate GateParameter.txt on your disk 
since it tells PupTest to startup the SLA Driver. Direct PupTest to Echo to itself through the 
looped back line; that is say Echo to: 7#n# where n is the assigned SLA network address 
for your machine. The normal behavior in this case is for "!" and "$" to be printed 
alternately. ("$" means that the Echo server, running on the same machine, replied to an 
echo request.) If this doesn't work, the SLA interface is probably broken. Be sure to plug 
the modem back in. 

5. After plugging the modem back in, press the al (Analog Loopback) button on the 
modem so that it stays in its "in" position. Again, direct PupTest to echo to itself through 
the SLA driver. If this doesn't work, the modem is probably broken. When you are 
finished with this test, be sure the modem's al button is in its "out" position. 

6. If the previous test worked, but it was not possible to echo to the Gateway at the other 
end of the link, then the failure is in the other Gateway or the modem at the far end of the 
link or in the leased line itself Determining which component has gone down requires 
cooperation with personnel at the far end. 

You can use the Echo command within the Gateway program rather than PupTest. If you do, it is 
probably a good idea to lock the display on with the T command first. Remember, it won't print 
"$" if you are echoing to yourself, but will move the cursor down one step instead. To force 
Echoing to go through a particular line, unplug all of the others. 

6. Notes to Gateway Maintainors 

Be sure to keep at least free 300 pages on your Gateway disk after Gateway .scratch$ has been 
deleted. If you don't have enough there won't be any way to remotely update big files. Actually, if 
you really need a few more pages, you can borrow some from a big boot file by storing DMl'.boot 
into it. 

When updating Gateway.image via GateControl, the Gateway program automatically changes the 
name of the incomming file on the Gateway disk to be NewG ate way .image. The GateControl 
Restart command looks for this filename. The running program is swapping code out of 
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Gateway .image, and it will probably die horribly if the code were changed out from underneath it. 

If a file already exists when an update starts, the incomming data is stored in a temporary file until 
it is all collected to protect against clobbering things if the EFTP transfer fails. If a file docs not 
exist when the update starts, the incomming data is written directly into the target file to avoid 
filling up the disk with two copies. If the transfer fiiils, the partial file is deleted. 

The Restart command appends a few commands into Rem.cm, so you can do almost anything you 
want to a Gateway disk remotely by storing your own commands in there ahead of its restart 
sequence. If NewGateway. image exists when the Gateway is being restarted, Gateway .image will be 
deleted and NewGateway .image will be renamed into Gateway.image. At die end is a command to 
run Gateway.image. 

Whenever the Gateway program starts up, it will reformat any boot files in its list that have not 
been previously refonnatted. That takes a while if it actually does any reformatting. Since most 
files are updated remotely via GateControl which also does the reformatting, this should not happen 
very often. NB: Since SYS.boot is needed to get the Alto off the ground, there is a special case 
check to avoid clobbering it. That's why there is a NewOs.boot rather than a SYS.Boot in the 
noimal boot file list. (ITiis problem docs not arise on the Nova Gateways since they don't use 
Sys.boot.) The boot file sender will give up if in encounters an un-rcfonnatted file. 

There is a way to run other programs along with the Gateway. If tlie file GateRun.txt is on your 
disk, the Gateway program will process it after things get started. It should contain lines of the 
form ;cxx.bcd followed by a carriage return. For each line, the Gateway program will load the bed, 
and FORK to its control module. The Gateway program exports GatcDcfs, and all the Pup 
interfaces, so you can easily link to its innards. There is a sample module Ihat uses this feature. It 
is called TimcChecker, and it will ask Portola for the initial time, wait about 24 hours, ask Portola 
for the time, and print out the difference. If the time has not been reset in the meantime, this 
should provide a correction factor for your clock. 

We use this feature to run the PacketRadio interface. If you need special microcode, you will have 
to cooridinate things carefully. 

If you are using this feature, you should be careftjl when updating your bcds remotely, remember 
that the running system is swapping code out of them. One correct recipe is to first store away an 
empty GateRun.txt. Then, restart the Gateway, store your updated bcds, and then restore the 
correct contents to GateRun.txt, and again restart the Gateway. For some reason that I have not yet 
tracked down, an empty file doesn't work. So I store Com.cm into GateRun.txt. If you are using 
Gatecontrol to do this, Com.cm will hold "GateControl.run". The Gateway program will recover 
from missing files, and that is a filename that is not likely to be found on a Gateway disk. 

If the Gateway program is forwarding a great deal of traffic, there will not be any CPU cycles left 
over for other things. This will probably only be noticable if you are trying to get a boot file while 
running PupTest between two machines connected to different Ethernets on the same Alto Gateway. 
The Gateway will support about 400 kilobits of throughput, but it may take over a minute to get a 
big boot file while that is happening. 

7. Hardware Requirements 

To run the Alto Gateway software requires appropiatc hardware. Here is a quick checklist: 

First, you need a 7th build or newer Alto. ITiese are the wide-bodied ones. You don't 
actually need any extra memory, but it is much easier to make the necessary modifications 
on tlic newer Altos. Mesa 4.1 must be blown into ROMl. 

If your Gateway is going to talk to a phone line, you will need cither an EIA board(s) or a 
CommProc. An EIA board costs about $1200 per line. It does not seem to run faster than 
about 20KIi, but I don't know why it doesn't. A CommProc costs about $4500 plus $500 
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per line. It works ok at 50KB. 

If you are using an eia board, mrt must be made Ram-Related. Connect mrtactive (slot 
11, pin 109) to either taska' (slot 10, pin 13) or taskb' (pin 14) whichever isn't being used 
by other devices. The CommProc uses taska'. 

ITie wire wrap eia board needs a patch for the loopback test to work: add a wire from BIO 
pin 11 (SYNCLK) to J3 pin 35. (I haven't seen a PC version yet, so I don't know if it has this 
change.) ITie CommProc needs a backplane jumper from Jll pin 108, for 9600 baud, or 
pin 111 for 57KB, to pin 105 of the slot containing the LIM driving the line. That brings 
an internal clock out to pin 18, which is normally unused, on the modem connector. An 
echo plug (its female) should have pin 2 (transmit data) connected to pin 3 (receive data), 
pin 4 (request to send) connected to pin 5 (clear to send), pin 6 (data set ready) connected 
to pin 20 (data terminal ready), and pin 18 (internal clock) connected to pins 15 (transmit 
clock) and 17 (receive clock). 

If you are going to connect to more than one Ethernet, you will have to aquire and install 
extra Ethernet boards. See [iVY] < Portola > ExtraEther.press. An Alto can handle up to three 
Ethernets. The Gateway software expects the first extra Ethernet to use task 2 and SIO bits 
12 and 13. It also expects the second extra Ethernet to use task 1 and SIO bits 10 and 11. 

The Alto-to-modem cable has a female DB-25 connector at tlic Alto end and a male DB-25 
at the modem end. The following signals should be transmitted through the cable: 



Pin 


Signal 


1 


Protective ground 


2 


Transmit data 


3 


Receive data 


4 


Request to Send 


5 


Clear to Send 


6 


Data Set Ready 


7 


Signal ground 


15 


Transmit clock 


17 


Receive clock 


20 


Data Terminal Ready 



If you have a CommProc, and you are adding a third Ethernet, you will have to undo the 
CommProc timer. It is not used by the Gateway. Remove the wires connecting pin 119 on 
slot 16 to pin 119 on slot 11 (lACT), and pin 114 on slot 16 to pin 114 on slot 11 
(WAKEr), or simply omit them when you install the CommProc. 

An Alto disk is quite full if you have the normal collection of boot files. If you want a 
large collection of boot files, or the Mesa Debugger and some symbols, a second disk drive 
will be necessary. 

Distribution: 

Ed Taft, David Boggs, Urry Stewart, Ted Strollo (Pare) 
Steve Buttcrficld, John Beeley (ASD) 
Tim Carroll (WRC) 



